Computerized transaction execution and processing requires an enormous amount of time and resources. The time and resources are required because, in most instances, execution and processing are based upon customized implementations of the transaction.
Customized transaction implementations require new programming. New programming requires cost and effort—not only for the first attempt, but also for the debugging and testing processes. Moreover, once the program is debugged and released, real world implementations require yet further testing and debugging.
One approach to simplifying programming effort is through object oriented programming (OOP). OOP methods encapsulate, or bind together, data and the methods that operate on data through the use of objects which can be copied, modified, manipulated, linked together, etc. The objects are usually grouped in object classes that have attributes such as data values and methods (functions). An OOP approach to programming usually produces results in less time and with less resource cost than previous programming approaches.
OOP also uses frameworks in an effort to further reduce program development costs. A framework is a set of OOP classes that embodies a predetermined set of attributes and methods for providing a common group of behaviors. An application program developer utilizes the framework and builds upon it, adding subclasses and attributes and modifying methods depending on the problem to be solved. The framework developers have to arrive at a set of classes and methods that will best provide the desired problem solution and will accept the most likely framework extensions.
Despite the availability and benefits usually obtained by OOP, few if any OOP objects, object classes and frameworks exist in the computerized transaction processing area. This lack of OOP tools may be for any number of reasons. For example, any type of programming takes resources and time. It takes resources because the programmers must first develop the program with input from the users, and then the users themselves must test the program in the field, to ensure reliable operation. The effort required means that the users may be too busy doing their job to assist in programming efforts. Thus the program may not ever be developed. Moreover, by the time any particular program is developed, the markets may have shifted away from the initial transactional conditions that first provided the impetus for developing the program. For example, specific trading strategies are usually constructed and executed on a customized basis, yet by the time the program is developed for those strategies, and those strategies are executed, they may be no longer useful.
The cost, effort and time factors are not solely the result of required programming. In trading transactions, the programmers must be advised by the traders or other business professionals regarding desired trading strategies and desired markets. These professionals are busy in their own right—they may have little or no time to advise the programmers on what new strategies and markets should be developed. Even if they can advise the programmers, trading strategies can become quite complex, and in order to communicate those strategies and implement those strategies effectively, the programmer and trader interactions cost time, money and resources.
Enterprise-wide customization adds yet another level of time, effort and complexity. What may be useful in one enterprise business unit may not be useful in another, and time, effort and resources may not be available to implement specific programs customized for each business unit.
Finally, any implementations must be quite robust, and reliably and consistently execute trading strategies. The implementation of new computerized transactional programs must be as close to bullet proof as possible—failure of a trading program can mean losses in thousands, millions or even billions of dollars. Developing reliable implementations of trading programs means that testing procedures and recovery procedures must always be paramount considerations.
Thus, the art has heretofore lacked effective, efficient programming tools, whether in OOP or otherwise.
Therefore, it is an object of this invention to provide an OOP programming tool or tools to allow users to more quickly develop, construct and execute computerized transactions.
It is a further object of this invention to provide robust and reliable apparatus, methods and articles of manufacture for implementing trading strategies.